home *** CD-ROM | disk | FTP | other *** search
/ ETO Development Tools 1 / ETO Development Tools 1.iso / Essentials / MacApp Documentation / MacApp AppleLink Messages / MacApp.Tech$ Aug 89 / X0004-Re building blocks-Aug89 < prev    next >
Encoding:
Text File  |  1989-08-22  |  2.9 KB  |  56 lines  |  [TEXT/GEOL]
  1. Item    0122005                         2-Aug-89        14:24
  2.  
  3. From:   BURBECK.S                       Burbeck, Steve
  4.  
  5. To:     CHESLEY1                        Chesley, Harry
  6.  
  7. cc:     MACAPP.CUP$                     MacApp Interest List - Cupertino
  8.  
  9. Sub:    re building blocks
  10.  
  11. Harry,
  12.  
  13. Sorry it took so long to reply to your July 18 link on Whither MacApp.  I
  14. printed it and it dissappeared into a pile that only just resurfaced.
  15.  
  16. First, about expansion to the class library vs. improvements to the
  17. underpinnings and/or tools:  Obviously both are vital.  But my focus for the
  18. "Whither MacApp" discussion was on elevating general awareness of the need for
  19. increases to the MacApp team.  As a broad generalization, only the MacApp team
  20. can do the underpinning work whereas additions to the class library can be done
  21. by others (and I gladly accept your offer to work on network building blocks).
  22.  
  23. One might argue that some additions to the MacApp building blocks OUGHT to be
  24. the responsibility of groups outside the MacApp team.  Consider a parallel with
  25. the writing of peripheral drivers.  When a new hardware peripheral is built,
  26. the team that builds it, not the system engineering team, is usually expected
  27. to provide the drivers for it.  This is both because the system engineers don't
  28. have the resources to write drivers for every new peripheral, but also because
  29. they don't necessarily have the detailed knowledge needed to write each driver.
  30. Similar resource and expertise issues arise with MacApp.
  31.  
  32. There are some important points that would-be building block designers should
  33. keep in mind.  MacApp building blocks are intended to be incorporated into our
  34. developer's products and are shipped with full source code.  Therefore MacApp
  35. building blocks must be coded with the realization that developers may treat
  36. each and every line of code as "Apple's Approved Way to Do It."  Developers
  37. will (perhaps uncritically) borrow techniques they see in our building blocks,
  38. and will likely cut and paste parts of the building block code hither and yon.
  39. Moreover, MacApp building blocks must be carefully designed for reusability --
  40. an art that few OOP programmers have mastered.  Reusable building blocks are
  41. inevitably used for things never imagined by the original designer.  Every
  42. latent inflexibility, weak point, hidden assumption and boundary condition in
  43. the code will be hit.  This puts an extra burden on the designer, but also
  44. requires substantial documentation and testing efforts.  Even if you and other
  45. volunteers were to do all the engineering of new building blocks, we still need
  46. additional tech pubs and testing resources that, at this moment, do not seem to
  47. be forthcoming.
  48.  
  49. All that aside, I certainly want to encourage people in the many groups that
  50. are using MacApp to think in terms of contributing additional building blocks.
  51. The MacApp team can't possibly do all that is needed even if it doubled or
  52. trippled in size.
  53.  
  54. Steve Burbeck
  55.  
  56.